lib/deploy: Use a FIFREEZE/FITHAW cycle for /boot
authorColin Walters <walters@verbum.org>
Thu, 3 Aug 2017 02:07:26 +0000 (22:07 -0400)
committerAtomic Bot <atomic-devel@projectatomic.io>
Tue, 8 Aug 2017 16:09:04 +0000 (16:09 +0000)
commit8642ef5ab3fec3ac8eb8f193054852f83a8bc4d0
tree4105371c58a3e719836e0d19a70b72508a22919d
parent9f8f351cd45e5dd0219c3177558b497ab10c58e9
lib/deploy: Use a FIFREEZE/FITHAW cycle for /boot

See: http://marc.info/?l=linux-fsdevel&m=149520244919284&w=2

XFS doesn't flush the journal on `syncfs()`. GRUB doesn't know how to follow the
XFS journal, so if the filesystem is in a dirty state (possible with xfs
`/boot`, extremely likely with `/`, if the journaled data includes content for
`/boot`, the system may be unbootable if a system crash occurs.

Fix this by doing a `FIFREEZE`+`FITHAW` cycle.  Now, most people
probably would have replaced the `syncfs()` invocation with those two
ioctls.  But this would have become (I believe) the *only* place in
libostree where we weren't safe against interruption.  The failure
mode would be ugly; nothing else would be able to write to the filesystem
until manual intervention.

The real fix here I think is to land an atomic `FIFREEZETHAW` ioctl
in the kernel.  I might try a patch.

In the meantime though, let's jump through some hoops and set up
a "watchdog" child process that acts as a fallback unfreezer.

Closes: https://github.com/ostreedev/ostree/issues/876
Closes: #1049
Approved by: jlebon
src/libostree/ostree-sysroot-deploy.c
src/libostree/ostree-sysroot-private.h
src/libostree/ostree-sysroot.c
tests/admin-test.sh
tests/test-admin-deploy-grub2.sh
tests/test-admin-deploy-syslinux.sh
tests/test-admin-deploy-uboot.sh